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In this paper, we formally define Test Case Sequence Diagrams (TCSD) as an easy-to-use means to 
specify test cases for components including timing constraints. These test cases are modeled using 
the UML2 syntax and can be specified by standard UML-modeling-tools. In a component-based 
design an early identification of errors can be achieved by a virtual integration of components before 
the actual system is build. We define such a procedure which integrates the individual test cases of 
the components according to the interconnections of a given architecture and checks if all specified 
communication sequences are consistent. Therefore, we formally define the transformation of TCSD 
into timed-arc Petri nets and a process for the combination of these nets. The applicability of our 
approach is demonstrated on an avionic use case from the ARP4761 standard. 

1 Introduction 

Testing is an important activity in modern embedded systems development processes, e.g., ISO 26262 (SJ, 
SAE ARP4761 [ Q. It comprises different level of granularity. In case of a component-based design Q 
the unit-tests have to validate that each individual component fulfills its requirements. The integration- 
tests deal with the problems that arise through the combination of multiple components and have to 
ensure their correct interaction. On the highest level, the complete system has to be validated. 

In this paper, we focus on two testing aspects. First, an easy-to-use specification method for unit- 
tests using UML2 syntax lfT2l . Second, we define an early virtual integration analysis on the basis of 
these test cases. For the test case specification, we introduce the concept of test case sequence diagrams 
(TCSD) as an extension of UML2 sequence diagrams. This extension allows test engineers to annotate 
timing constraints for messages in the test case specification. Out of these test cases we are then able to 
generate a formal analysis model to perform the virtual integration analysis. 

The main idea of this approach is to interpret the successfully executed unit-test cases as contract 
specification for the component. The pair of input and expected result defines the assumption and the 
promise on the connected input ports and output ports respectively. On the basis of these specifications, 
we are analysing if test cases for different components of the same system contradict each other regarding 
timing behavior or the ordering of messages. 

Our main contribution is the formalisation of sequence diagram-based test cases and the virtual in- 
tegration analysis of the test cases. This approach is demonstrated on a well-known aerospace example 
from the ARP4761, the braking system control unit (BSCU). The components of the BSCU are imple- 
mented using Matlab/Simulink and sequence diagram-based test cases and the system architecture of the 
BSCU are modeled using IBM Rational Rhapsody. These test cases are translated into timed-arc Petri 
nets (TAPN) Q, which are modeled and analyzed using the tool TAPAAL |4]. For the virtual integra- 
tion, we developed a prototype which is able to export the necessary information from Rhapsody. It also 
translates the exported TCSD into timed-arc Petri nets, which can then be analyzed by TAPAAL. 
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The structure of this paper is as follows: The formal definition of sequence diagrams, test case 
sequence diagrams, and Petri nets is described in section [2] Section [3] presents the virtual integration 
process, including the translation mechanism of TCSD to TAPN. The demonstration of our analysis is 
evaluated in section [4] and in section [5] a conclusion as well as an outlook for our future work is given. 

1.1 Related work 

There is a huge amount of publications available dealing with UML [12] models for test case spec- 
ification. For example Sokenou lfl4l identified the need to include sequence diagrams and state dia- 
grams, which are usually created in the early stages of the development, into his test sequence generation 
method. Also Linzhang iPTOll described the UML models as a natural source for test case generation, 
since this semi-formal modelling language is commonly used. 

The formalization of sequence diagrams has been analyzed in ||9j[TTl|6l as wei l as their transformation 
into other specifications. For example Bowles [2] formalized sequence diagrams and translated sequence 
diagrams into coloured Petri nets. In this paper, we use his formalism for sequence diagrams but translate 
them into timed-arc Petri nets (TAPN), because of the annotated timing information. We chose Petri nets 
over timed automata lfl"5ll because of the simplicity to compose different Petri nets in parallel [16]. 

The background of this work is based-on prior work [13] in which the idea of sequence diagram- 
based test case specification is introduced as well as the concept for consistency analysis. This work 
elaborates on these ideas and creates a formal model for the test case sequence diagrams. We also define 
the virtual integration analysis on the formal model of TCSDs. 

2 Formal Definitions 

This section introduces the formal models for our virtual integration, namely sequence diagrams, timed- 
arc Petri nets, and test case sequence diagrams. 

The basic models for UML sequence diagrams and timed-arc Petri nets are both based-on existing 
formal models, whereas test case sequence diagrams are a new extension to sequence diagrams specifi- 
cally designed to suit the specification needs of timed behavior of a system under test. 

2.1 UML Sequence Diagrams 

The semantics of sequence diagrams, we use in this paper, are based-on the informal specification in 
the UML 2.0 superstructure [12] and the formal semantics defined in Bowles and Meedeniya 0. In 
addition, we define a slightly adapted version of these semantics, named test case sequence diagram 
(TCSD), to deal with diagrams specifically designed for test cases. Figure [T] shows an example of a 
TCSD and introduces the basic idea of the formalization, which is based-on the different types of events 
on the instance lines. 

Definition 1 (Sequence Diagram (based-on [2])) 

A sequence diagram (SD) is a tuple D = (d,I,E, <,Y imsg ,M,F,X ,Exp) where: 

• d 6 ^name i- s me name of the diagram and ^name the set of all diagram names; 

• / is a finite set of object instances (lifelines); 

• E = \J jeI Ei is a set of events for lifeline i, s.t. V/, j € / :EiC\ Ej = 0; 

• < is a set of partial orders which defines for instance line i £ I a set: <,C £, x Ei; 
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Figure 1: The figure shows examples of 
the structural elements of test case se- 
quence diagrams and their different types 
of events. 

For example: The box labeled with SUT 
is the instance line of the system under 
test, which interacts with the test compo- 
nents 1 & 2; the arrow labeled with l\ is 
a message sent by event en and received 
by ^21 ; the horizontal line with events 
£i2> ?22, and £31 is a partition line which 
models a timing constraint of 10ms; the 
box labeled with par is a fragment in 
which the events of the two operands, 
seperated by the dashed line, are executed 
in parallel; and the arrow between event 
e25 and e 2 $ is a timeout operator, which 
constraints the time between the occur- 
rences of these events to 5ms. 



• L msg is a finite set of message labels I; 

• M is a set of messages M C E x zZ msg x E, s.t.for every m\,m 2 G M with m\ = {e\\,l\,e\ 2 ) and 
m 2 = (e 2 i,l 2 ,e 22 ): m\ ^m 2 => e n ^e n ^e 2 \ / e 22 ; 

• F is a set of interaction fragments for which the functions op,ev,sub are defined as: 

— op : F —7- QxN associates an operator D. G {strict, par, opt, alt, loop} and 
the number of operands to a fragment; 

— ev : F x N — > 2 E associates a set of events to a pair (id,n) of a fragment id G F and an 
operand index number n; 

— sub :FxN-^2 F associates a set of nested fragments to a parent fragment and an operand 
index number; 

• X = {Xi}i e j a set of local variables indexed by object instances i G I; 

• Exp is a set of expressions, where each expression is associated as a guard to a message or a 
fragment using the function guard : MUF — > Exp 

A sequence diagram as defined in Definition [T] has a name d, which is usually used to identify a diagram 
in a UML modeling tool and a set of object instances /. Each instance i G / describes the behavior of one 
object in the diagram, which is defined by the events Et on the lifeline. All events within the diagram 
are partially ordered by a relation <,. Only a partial ordering is possible, because the events in operands 
of fragment blocks like par cannot be ordered. An event of a sequence diagram can either be part of 
a message (send event/receive event) or mark the borders of an interaction fragment (enter event/exit 
event). The interactions of a sequence diagram are defined by its transitions (messages) and the different 
kind of fragments. Each message m is a tuple m = [e\ , h, e^) where e\ G E,- is a send event, l\ is a message 
label of the labeling alphabet L msg , and e 2 G Ej is a receive event. Both events must be different {e\ ^ e 2 ). 
In addition, the events must be ordered (ei < e 2 ) if they are part of the same instance line (i = j). 
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Fragments are regions within a sequence diagram with a specific semantic defined by the operator Q. 
of the fragment. A fragment spans over a subset of all instance lines of the diagram and every instance 
part of the fragment has dedicated enter and exit events which signal the fragments boundaries with 
respect to this instance. The operators strict, par, alt, opt, and loop are relevant for our 
virtual integration scenario. The behavior of strict is the default behavior and requires that the events 
on the lifeline must occur in the specified order (according to the <,-relation). A par fragment has at 
least two operands. Starting with the enter event, the event sequences of all operands are executed 
in parallel. The exit event of the par fragment is reached when all operands have reached this event 
following the ^-relation. In contrast to the parallel execution of the par fragment, the operands of the 
alt fragment (at least two) represent exclusive alternative event sequences. The optional behavior of the 
opt fragment can be considered as a special case of an alt fragment, with one operand and an implicit 
empty sequence as second alternative. The loop fragment has exactly one operand. Its sequence of 
events is repeated as often as stated in the expression of its guard Exp(fi oop ). 

For each fragment three functions op, ev, and sub are defined: 

op : The op function assigns to each fragment an operator and the number of operands within the 
fragment. Each operator of a fragment requires a specific (minimum) number of operands. The 
strict, loop, and opt for example require exactly one operand, while the par and alt 
operators require at least two operands. 

ev : The ev function defines which elements are part of an operand. Therefore, it maps a tuple (f,n) of 
a fragment / and an operand number n to a set of events. 

sub : In sequence diagrams fragments may be nested. The function sub describes this hierarchy by 
mapping a tuple (f,n) to the set of the directly nested fragments within the nth fragment and 
therefore establishes a parent-child relation. 

To avoid ill-formed fragment and event hierarchies, all fragments of a sequence diagram must fulfill 
a set of consistency properties, s.t. for any fragments /i,/ 2 £ F with f\ 7^/2, op{f\) = {o\,n\) and 
°p{fi) = {02,112) the following properties must hold: 

1. no self-nesting: f\ ^ sub{f\,x) for any x<n\ 

2. no shared events (except if nested): Vxi < n\,x% < «2 : fi ^ sub(fz,xi) A/2 ^ sub(fi,X2) ==> 
ev(/i,xi)nev(/ 2 ,x 2 ) =0 

3. containment of events: / 2 G sub(fi,Xi) ev{f\,xi) 5 U«<n 2 ev {hi n ) 

The first property avoids that any fragment may be nested in itself. The second property requires that 
any two disjunct fragments must not share events. The third property requires that if two fragments are 
nested the parent fragment must contain all events of its child fragments. 

A sequence diagram can also contain a number of variables X and expressions Exp which are used 
on messages and fragments as guards. Apart from constant expressions on loop fragments, the variable 
and expression concepts are not relevant for our virtual integration analysis and are therefore ignored in 
the rest of this paper. 

2.2 Test Case Sequence Diagrams 

In our approach, we extend Definition [T] to test case sequence diagrams (see Definition [2]), which are 
able to model the timed behavior of a test case. In a TCSD the object instances have two different 
roles. One instance represents the component of the system under test (SUT) for which the test case 
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is defined. All other object instances of the diagram represent test components. Test components are 
abstract components which will (in most cases) not appear within the real system architecture. Their 
only purpose is to provide input to and receive output from the ports of the SUT. 

Therefore, we limit the set of events in messages, such that either the sending or the receiving event 
must be part of the sut object instance and the other event must be part of a test component. Self loops 
on the SUT are not allowed because the idea of the test components is to make the communication with 
the SUT visible, such that messages to the SUT can be interpreted as part of an input test vector and 
messages received from the SUT as part of the expected output. 

TCSDs also allow the specification of timing constraints on events. To this end, the diagram type 
supports partition lines % G & with T = (e\, . . . , e m , 8) which are annotated with the timing information 
8. A partition line cuts through all instance lines by introducing a new event in each line. Each TCSD 
has an implicit partition line To with 5 = which indicates the start of the diagram. Every time stamp 
of following partition lines is relative to this initial line. The semantics are that every event before a 
partition line event has to happen before the annotated time stamp 8 and every following event at least 
after 8 time. 

The consistency of partition lines is ensured by additional properties. The uniqueness property (1) 
requires that there are no two partition lines with the same time stamp. The completeness property 
(2) ensures that all instance lines have a partition line event separating their own events. The ordering 
property (3) ensures that the annotated times on all partition lines are in an ascending order. The last 
property (4) prevents the intersection of partition lines with fragments. 

For the ordering of two partition lines we will write X\ < % 2 as a short form for comparing the time 
steps 8\ < 8 2 . 

To express timing constraints within a (sub-)fragment of the SUT instance line, a TCSD supports the 
concept of timeouts, which are represented by the set c € . Each timeout is a tuple c = (e\ , e 2 , 8) consisting 
of two ordered events between which at most 8 time units may pass. A timeout may be used within a 
subfragment, but both events of it must be part of the same fragment operand. 

Definition 2 (Test Case Sequence Diagram) 

A test case sequence diagram (TCSD) is a tuple TC = <,Z mS g,M,F,X,£jc/?,.raf , 2? ^) where: 

• (d,I,E,<,lL mS g,M,F,X,Exp) is a sequence diagram; 

• sut £ I is the system under test instance line; 

• for every m£M with m = (e\ , I, e 2 ) : {e\ G E m Ae 2 ^ E sut ) V (e 2 G E m Aei<£ E sut ) 

• ST C £"I 7 I x No is the set of time partition lines, s.t. for every Zi,z 2 G ST with %\ = (en, ■ ■ ■ ,eim, 8i) 
andx 2 = (e 2 \,...,e 2m ,8 2 ): 

1. uniqueness: 8\=8 2 X\ = T 2 

2. completeness: Veu,eij : i^= j 44> Ej ^ Ej 

3. ordering: Mj : (5i < 8 2 ) «4> (e\j,e 2j ) G Ej => (eij,e 2j ) e<j; 

4. no fragment cutting: V/i G with op(f\) = (oi,«i),V« < n\ : e\\, . . . ,e\ m ^ ev(f\,n) 

• ^ is a set of timeouts <?f C E mt x E mt x N, s.t. for every c = (e\,e 2 , 8) with e\,e 2 G E sut : 

1. ordered: e\ < e 2 

2. same fragment: V/EF with op(f) = : e\ G ev(f,x) 44> e 2 G ev(f,x) for any x < n\ 
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2.3 Timed-arc Petri Nets 

In this section we will recall the formal definition of TAPN and introduce our notation which will be 
used in the rest of the document. 

Definition 3 (Timed-arc Petri nets (based-on 0) 

A timed-arc Petri net with transport arcs (TAPN) is a tuple N = (P, T,R,c,R tarc ,c tarc ,l), where: 

• P is a finite set of places; 

• T is a finite set of transitions (POT = 0); 

• R is the flow relation (RC (PxT)U(T x P)); 

• c is a function that associates a time interval to each arc (p,t) in R, s.t. c : R\p X T ^ I 

• Rtarc C (P x r x P) is the set of transportation arcs that satisfy for all (p,t,p') G R tarc and all 
r G P: ((p,t,r) G R tarc => p' = r)A ((r,t,p') G R taK => P = r) A (p,t) <£RA(t,p') (£ R 

• Ctarc '■ Rtarc —> associates a time interval to every transportation arc; 

• l : P — > J^j m , assigns time intervals as invariants to places. 

The TAPN can be seen as a directed bipartite graph of separated places P and transitions T. The inter- 
connection of the net is given by two flow relations. R defines arcs between places and transitions in both 
ways as known from conventional Petri nets, whereas R tarc defines so-called transportation arcs. The 
main structural difference between those two kinds of arcs is that transportation arcs are always triples 
from a place over a transition to a place. The other arcs are separate tuple for arcs to a transition (p,t) 
or arcs from a transition (t,p). The additional condition on transportation arcs imposes, that there is at 
most one transportation arc between any two places. 

In contrast to the original definition [3], we limit the supported time intervals J? and J^j m , to be only 
closed [-,-] or right-open [•, •) intervals over No x (No U {°°}). Other kinds of intervals are not relevant for 
our virtual integration analysis. In addition, invariants are also not considered and we assume the default 
invariant [0,°°) for every place. 

In the following we will use p t as a short notation for the arc (p,t) with an associated time 

interval [t,t) and p ^-k- 1 — > p' for a sequence in a TAPN ./V where (p,t), (t,p') G Rn and Cff(p,t) = [i,t). 

For transportation arcs we use the notation p — ♦ p' respectively. 

The state of a Petri net is defined by its current placed tokens (marking). In a TAPN each token 
has an individual age which increases over time. Formally a marking M on a TAPN Af is a function 
M : P — > 2 R o which assigns every place p G P a set of positive real numbered tokens, s.t. each token 
x G M(p) of a marking fulfills the invariant of its assigned place: x G l(p). Only markings with a finite 
number of tokens are considered in this paper. 

A marked TAPN is a tuple (N,M Q ) of a TAPN Af and a marking Mo over the places of N. The 
dynamics are defined over changes of this marking, which follow the flow relations R and R tar c- A 
transition t is said to be enabled if there exists at least one token in each of the places connected to its 
incoming arcs according to R for normal arcs and R tarc in case of transportation arcs and these tokens 
are in the corresponding timing interval of c and c tarc respectively. In addition, the tokens of normal arcs 
and transportation arcs have to fulfill the invariants of the target places. An enabled transition can fire 
by consuming exactly one token of matching age from each of its incoming arcs and producing one new 
token of each of its outgoing arcs. The age of these newly created token is either 0, if it is produced 
by a normal arc, or the age of the consumed token, if it is produced by a transportation arc. Instead of 
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firing a transition, a TAPN can perform a so called time delay in which the age of all token of the current 
marking is increased by the same timespan. The time delay is valid if all token still fulfill the invariants 
of their corresponding places. We write M 4 M' if the marking M' is reached from M by consuming 
t time units and firing enabled transitions of the TAPN. A marking is said to be reachable from Mq 
within k steps, if there is a sequence M; -4 Mj + \ for < i < k and i, k G No. 

For the construction of TAPNs from sequence diagrams, we need to be able to identify transitions 
with messages of the diagram. Therefore, we define a labeling function Xtrans '■ T — > E trans , which asso- 
ciates each transition of a TAPN with a label from a labeling alphabet r /rans . 

3 Virtual Integration of Sequence Diagrams 

In the virtual integration scenario all TCSDs of the individual components are combined according to 
the interconnections of the ports provided by the system architecture. The procedure consists of three 
steps: First, the TCSDs are translated into TAPNs, which mimic the occurrences of the SUT events 
and impose the same timing constraints; Second, the individual TAPNs are combined to a single TAPN 
by synchronizing the communicated messages according to the architecture; And third, a consistency 
analysis is performed which checks if it is possible to successfully execute the combined TAPN. 

3.1 Translation of TCSDs to TAPNs 

For the translation of TCSDs to TAPNs we define a set of translation rules. The general idea is to 
construct a sequence of transitions (main sequence) in which each transition represents exactly one event 
of the SUT instance line. In the TAPN a single token is transported among this sequence and mimics the 
execution of the sequence diagram. The age of the token on the main sequence is restricted by timing 
constraints on the transitions according to the constraints on the partition line. Figure [2] shows the idea 
of the construction of the main sequence. 




Figure 2: Example of the translation procedure of a TCSD to a TAPN. Subfigure a) shows a basic TCSD 
with the sequence of messages x, y, z and required timing-constraints. Subfigure b) shows how the 
message events relate to labeled transitions on the main transportation arc sequence of the TAPN. The 
timing-constraints are enforced by the interval guards. Subfigure c) shows the resulting marked TAPN 
including a place with a token and the delay transition at the beginning. 



24 



TCSD Specification and Virtual Integration Analysis using TAPN 



Messages are represented as labels on transitions. They don't add any additional semantic to the net, 
but are used for synchronization with other nets. Fragments and timeout events on the other hand, are 
translated by adding branches (one for each operand) to the main line. Each branch starts at the enter 
event transition and is merged again with the main line on the corresponding exit transition. 

The formal construction is defined by a set of translation rules. Each rule applies to one kind of 
event. Their input on the one hand is the TCSD TC which has to be translated and an event e c G E sut of 
the SUT instance line which marks the current position in the diagram. On the other hand the other input 
is the so far partially generated TAPN PN and a place p c to which the new Petri net elements have to be 
appended. The place p c is either the last place of the generated main sequence or the end of the current 
branch, if e c is part of a fragment operand. The output of the rule is an extended net PN' and the next 
event e' c . 

For the notation of the rules we will mark every new TAPN element added to PN with a prime. We 
will also use the function next to indicate the immediate following event within the SUT instance line 
according to the < relation of the diagram. In case there is just a partial ordering because of multiple 
operands in a fragment, the rules will iterate the events of the operands sequentially. Intuitively, the 
transformation rule iterates over all events on the SUT instance line according to the graphical notation. 
If next (e) = then the event e is the last event on the instance line. In addition, the functions first 
and last are used to identify the first respectively the last event of a operand according to the ordering 
relation. Each rule consists of a formal description and a figure of the TAPN artifacts created by the rule. 
Places in red mark the attachment point to the prior constructed TAPN elements. Dashed lines indicate 
segments which have to be further extended. 

The transformation process consists of a succeeding application of the different translation rules and 
an iterative construction of the corresponding TAPN. Initially, Translation Rule[T]is applied which creates 
the initial places and the marking Mq. Afterwards the Translation Rules [2]-[7] are applied according to the 
type of the current event e c . They extend PN with a TAPN fragment modeling the sequence diagram 
event type until the last event has been handled (next(e c ) = 0). Then the final Translation Rule [8] can 
be applied, which creates the marking M target indicating the target state to be reached from the TAPN 
(PN,M ). 

Translation Rule 1 (Initial) 

[0,oo) 

Let e c G E sut and PN be the empty TAPN. Create p c — — > t > p c . with 

A'(f') = £, e' c = e c , and an initial marking Mq consisting of a single 
token on place p c with age 0. 

Multiple sequence diagrams may be executed with an arbitrary time offset. Therefore, we prefix the 
main sequence with a transition, such that the TAPN can initially wait. The Translation Rule [T] adds a 
transition with normal arcs and no timing constraint before the first event of the TCSD. This models an 

n [°'°°) 

arbitrary offset between the starting times of all TCSDs, e.g., FigureUAc) 50 — — > start — > P0. 



Translation Rule 2 (Send/Receive Message Event) 

Let e c G E sut where 3m EM, s.t. m = (e c ,l,e) orm = (e,l,e c ) and p c G 

P. Append p c ■ ' ^ t' — with X'(t') = I and e' c = next{e c ) 



Pc t> Pc 



Pc t' P'c 
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After the application of the initial rule, the other rules generate transportation arcs according to the 
events on the instance line. Translation Rule [2] models the sending and receiving of messages by adding 
a transportation arc to the main sequence with no additional timing constraints. The created transition t' is 
labeled with the label of the message. This label identifies the message (e.g., it contains the port identifier 
and the sent/received content) and is later used for synchronization with other TAPNs, e.g., Figure [T] 
m = (e u ,h,e 2 \). 

Translation Rule 3 (Partition Line Event) 

Let e c E E su , where 3r = (ei,...,e n ,e c ,e m ,...,ei,8) and p c E P. Ap- 
pend p c — — with X'(t') = E and e' c = next{e c ) 

The timing constraints imposed by partition lines are also encoded by adding a single transportation arc 
to the main sequence of the graph. The interval [8,8] limits the age of the main token to exactly 8 
in order to fire this transition. This represents the semantics of partition lines, s.t. all events before the 
partition line have to be executed before time stamp 8 and all events after the partition line can only be 
executed after time stamp 8. 



Translation Rule 4 (Par-/Alt-/Opt-Fragment Event) 

Let e c E E sut where 3f E F with op(f) = (£l,N) with £1 E 

{par, alt, opt} and e c is enter event of f: 

a a I ' 00 )*,' ▲ > / 
Append Pc ¥f rStan ^Pf - start Vf-end *Pf-end' 

For each operand idn <N do: 

1. Append t' f _ start — ► p' op - star t 

2. Apply Rules [2]-[7] starting with e c = first (ev(f,n)) and p c = 
Pop-start until e' c <£ev(f,n) 

[0 <») 

3. Append p op _ end — * t' f _ end with p' op _ end = p' c after step 2. 
Finally, set p' c = p'f_ end and e' c = next{e c ). 

Fragment blocks alt, opt, par [12] and the possible hierarchical structures thereof are encoded 
by adding additional paths, branching from the main sequence for each operand of the fragment. The 
main sequence is extended by two transitions. The first transition t'f_ start represents the enter event 
of the fragment and the second t't end the corresponding exit event. A new branch starting from 
t'f-start an d ending at ty_ end is added to the main sequence for each of the operands of the fragment. 
The branches itself are constructed according to the normal Translation Rules [2]-[7] This construction 
effectively reduces the alt and the opt fragments to the parallel execution construction of par. The 
motivation is that the resulting TAPN shall represent all possible execution paths of the original TCSD 
in order to provide all possible synchronization points for the virtual integration with other TAPN. 

Translation Rule 5 (Strict-Fragment Event) 

Let e c E E sut where 3f E F, op{f) = (Q,N) with £1= strict and e c 
is enter event of f: Set e' c = next(e c ) 



PC tl P'c 
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Translation Rule [5] handles strict fragments |[T2l . which is the default semantic in our construction. 
Therefore, it does not require any additional handling and the corresponding enter and exit events 
can be skipped. 



Translation Rule 6 (Loop-Fragment Event) 

Let e c 6 E sut where 3f £ F, op(f) = (CI, 1) with Q, = loop, 
guard(f) = N with N G N, and e c is enter event off: 
Mij a , P.-) a., [OH, 



Append p L 



'-+t' 

▼ /- start 



~^P'f-start 



f—end 



V,. 



end' 



1. Append t' f _ mn > p\_ stan 

2. Repeat N -times: 

• Apply Ride s [2]-[7| s tarting with e c = first (ev(/, 1)) an<i p c 

P'l-start Until e 'ci ev {fi n ) 

p' c after step 2. 



[o °°) 

3. Append p\_ end t' f _ end with Pl _ end 



Finally, set p' c = p'f_ end and e' c = next(e c ). 




The loop fragment is only supported if its guarding expression is a constant number. The construction 
described in Rule [6] is similar to the construction used for the par fragments. Except it is limited to 
a single operand and instead of adding multiple branches, it extends the looping branch starting with 
P'l-start N-times where is the number of unrollings of the loop. 



Translation Rule 7 (Timeout Event) 

Let e c £ E sut where 3c = (e start ,e end , 8) £ with e c = e stan : 



[o. 



▼ 'to 



~~^Pto- start 



1. Append p c w-to-start 

2. Apply Rules |2]-[7| starting with e c = next(e c ) and p c = p' to - start 



until e'=e 



end 



3. Append p' w _ end 
2. 



V 

▼*f, 



to— end 



♦p' with p' nd = p' after step 



4. Append t' ti 



to— start 



Pwait 



to— end 



Pc Restart p to _ start 




Timeout events define a timing constraint between the occurrences of the start event e sta rt and the end 
event e en d, eg., the timeout operator (e25,e29>5ras) in Figure [T] constraints the time between the oc- 
curences of the events ^26)^27, ^28 to 5ms. The construction described in Translation Rule [7] creates a 
new transportation arc on the main sequence for each of these events and a connected place with the 
corresponding timing constraint as interval. In contrast to fragment event rules, this rules constructs all 
events between e start and e en d directly on the main sequence rather than on a branch. 
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Translation Rule 8 (Termination) 

Let e c G E sut of SD and p c G P ofPN. If next (e c ) = then PN is the 
transformed TAPN of SD with correspondence in timed reachability 
of the marked TAPN (PN,Mq) to a marking M target , where Mo is the 
initial constructed marking and M target is a marking consisting of a 
single token (with arbitrary age) on p c . 

The translation process terminates with the application of Translation Rule[8] This rule is only applicable 
if the end of the SUT instance line is reached (next(e c ) = 0) and it creates the target Marking M target 
representing the state after the execution of the TCSD in the constructed TAPN. 

3.2 Synchronization of TAPN 

The virtual integration is done according to a system architecture A, which instantiates components and 
specifies how they are interconnected. Each component is associated with its own set of test cases, 
specified as TCSDs. Within a TCSD the component itself is identified as the SUT instance line. The 
other instance lines are test components, which represent virtual communication partners for the ports of 
the component. 

Given the connection between the ports of the components within the architecture it is possible to 
create a mapping of all test components to existing components of the architecture. This mapping directly 
corresponds to a mapping of SUT instance lines and test component instance lines. 

We write i\ =4 i 2 for two instance lines i\ G /] and i 2 G I 2 to indicate that i\ and i% are in a mapping 
relation according to the interconnections of the architecture A. 

The synchronization of these instance lines is done on the basis of the messages transmitted on the 
common ports. For the compatibility of messages we define a similar relation in Definition [4] Two 
messages are compatible if their source and target instance lines are in the mapping relation = 4. 

Definition 4 (Compatibility of Messages) 

Let TC\, TC2 be two TCSD with TC\ 7^ TC2 and A be an architecture connecting the components: 
The compatibility =a of two messages m\ = {e\\,l\,e\ 2 ) G Mjq x with e\\ G Ei n ,e\ 2 G £; 12 and m2 = 
(e 2 \,l 2 ,e 22 ) G M TCl with e 2 i G E hl ,e 22 G E hl is defined as: (m x = A m 2 ) := (in —a in) A (h = h) A 
{in —a in) 

Given this definition of compatibility, we can combine multiple TCSDs by synchronizing all compati- 
ble messages of the two diagrams. This synchronization process is in general not unique e.g., if there 
are multiple instances of messages with the same label). In this case all combinations of potential syn- 
chronization points have to be considered. To this end, we transform each individual TCSD into its 
corresponding TAPN. In the TAPN representation, each message is represented by a unique transition 
(see Translation Rule [2]). In case of a synchronization, the two transitions representing the compatible 
messages can be combined to a single new transition as depicted in Figure [3] Formally, all sets and func- 
tions of the two TAPN are merged, new transitions are introduced replacing the individual synchronized 
transitions, and the arcs are redirected to the new transitions. 

3.3 Consistency Analysis 

After all individual TAPNs are merged to a single net, the final step of the virtual integration analysis is 
to determine if this TAPN is consistent. Consistency in this case means that the target marking of the 
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Figure 3: Example of the combination of two (partial) TAPNs. The two transitions t\ and t% of the nets 
on the top are synchronized by replacing the transitions with a newly created transition t merge j. All arcs 
(transportation and normal) to t\ or t% are redirected to t merget i- The places in this figure are numbered to 
identify them in the merged TAPN. 



combined TAPN (the union of all individual target markings) is reachable from its initial marking (the 
union of all initial markings). 

This procedure detects timing constraint violations and ordering inconsistencies of messages. Timing 
constraints in the constructed TAPN relate to interval bounds (lower and upper) on the age of the token 
on the individual main sequences and the token of timeout operator branches (see Translation Rule [7]). 
If two or more nets have to synchronize on a common transition the ages of these token must still fulfill 
their guards even if the token have to wait additional time for the synchronization. Formally, the analysis 
has to check if all interval constraints on synchronized transitions have a non-empty intersection. This 
ensures that at least one successful execution of the integrated components fulfills all timing constraints. 

The second detectable kind of inconsistency is the problem regarding the ordering of messages. If for 
example one test case defines a strict ordering of two messages m\ and mj and a second test case specifies 
the opposite ordering of first mi and then m\, the merged TAPN can never reach its target marking. 
The messages m\jm% in both test cases are translated into transitions t\Jt% according to Transition Rule 
[2] After synchronizing the transitions, the net has a classical deadlock in its transitions: t\ can by 
construction only fire after ti fired, but ?2 has to wait until t\ fired. 

In case there are multiple possibilities to synchronize two nets, the analysis has to consider all possi- 
ble points of synchronization. For our analysis we consider it as sufficient, if at least one of the combina- 
tions succeeds the reachability analysis. Alternatively, one could impose a stronger consistency concept 
if it is required that all possible combinations pass the analysis. 

In general test cases define only the fragment of the total component behavior which is relevant for 
the test case. Therefore, the specified message sequences are in most cases incomplete. This can lead 
to a false inconsistent result of the analysis. The prior mentioned inconsistent sequence mi then ni2 may 
be consistent if we assume that the second test case just neglected a first occurrence of mi e.g., the full 
sequence would be mi,m2,mi. Therefore, inconsistency results may just be cases of underspecified test 
cases. 
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4 Evaluation 

We demonstrate the virtual integration analysis presented in this paper on an example that is complex 
enough for our purpose but still has an acceptable degree of simplicity to understand the context. The 
Brake System Control Unit (BSCU) is part of a Wheel Braking System (WBS) example that was used to 
describe the safety assessment for certification of civil aircraft in the SAE standard ARP4761 CQ. The 



architecture of the BSCU, which consists of two redundant subsystems, is shown in Figure 4a 
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(c) Test case with SUT Monitorl 
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(d) Test case with SUT Switch 



Figure 4: Subfigure a) shows the component model of the BSCU. Subfigures b) - d) depict test cases 
used for the demonstration of our approach. The SUTs and test components of each test case are mapped 
on the corresponding component in the shown architecture. 



We created a set of test cases to demonstrate our approach. These test cases represent the interaction 



of specific components of the BSCU, e.g., a test case for the Command unit (Figure 4b I, Monitor (Figure 



4c ), and the Switch (Figure 4d I. Applying our approach, each of these sequence diagrams is translated 



into one timed-arc Petri net. The three resulting Petri nets are then being merged into one single TAPN, 
see Figure [5] 

The translation rules introduced in section 3.1 can be identified in Figure[5] For example a translation 



of a partition line (Translation Rule[3j can be seen in the top left corner (P20 L °'°^ f — ♦^l). Another 
example is a realisation of the par-operator (Translation Rule 14b. Its main sequence is represented by 
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Fll ^-^h — — -% 2 — 4P27 and its branches are starting at the places P22 and P23. 

Performing the consistency analysis means that the target marking M = (EndrcsD Mon ,EndTcsD c om , 
EndjcsD s witch) is reachable. In this case, the target marking is not reachable because of a deadlock, 
caused by the transitions Status, CMDlm, AntiSkidlm, CMD1 and AntiSkidl. Since this is detected by 
our analysis, we are able to fix this error before the integration of the real system. 




EndrcsD_S\nuh 

Figure 5: Merged timed-arc Petri net of the test case sequence diagrams. 



5 Conclusion 

We presented an approach to analyze sequence diagram-based test cases. Therefore, a concept of test case 
sequence diagrams was introduced, which allows to annotate timing information to test cases. In order 
to formalize these test cases we extended the sequence diagram formalism of Bowles by the additional 
timing information. In addition, we adapted the Petri net formalism of Byg to represent the needed test 
case elements. For the translation of a TCSD into a TAPN, a set of translation rules was presented. These 
TAPNs can be merged into one single Petri net. On the basis of the merged Petri net, we were able to 
analyse if a set of test cases is consistent in the sense of ordering and timing behavior. 

The applicability of the approach was demonstrated using a example from the ARP 4761. We used 
IBM Rational Rhapsody to specify test cases for this BSCU and developed a prototype to extract the 
sequence diagram-based specifications. It also translates them into a TAPN to enable the analysis. 

In the future we want to evaluate this approach on a larger scale design process, in which our TCSDs 
are used for requirements specification as well as for test cases. In addition, we want to extend the scope 
of the analysis to enable support for life sequence charts 10. This will enable the integration of the anal- 



S. Sieverding, C. Ellen & P. Battram 



31 



ysis into the early stages of the development process, e.g., to analyse requirements for early verification. 
Other forms of synchronization of TAPNs, e.g., check for time interval inclusion in request/response 
scenarios are also planned. 
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